fix(engine-bridge): enforce LRU bound after revalidation - #225

Summary

Prevent ChainStateCache.revalidate() from resurrecting an evicted entry without reapplying the configured maxEntries LRU bound.

The successful background-revalidation path now enforces the same cache-size limit as the cache-miss path. A deterministic deferred-promise regression test covers eviction while revalidation is pending and verifies the resulting LRU order.

Related Issue

Closes #201

Changes Made

• Call evictIfNeeded() immediately after a successful background revalidation write.
• Add a deterministic asynchronous regression test that:
  • starts a delayed revalidation for stale entry A;
  • evicts A while its refresh is pending;
  • resolves the refresh and reinserts A;
  • verifies the cache never exceeds maxEntries;
  • verifies the final LRU order is D followed by refreshed A.
• Preserve existing stale-while-revalidate behavior, error handling, and isRevalidating reset behavior.
• Add no dependencies or new production APIs.

Testing Performed

• Unit tests pass (cargo test / npm test)
  • Focused ChainStateCache suite: 11 tests passed.
  • Full engine-bridge suite: 87 tests passed across 13 suites.
  • Rust workspace: 95 tests passed.
  • Dashboard: 129 tests passed across 16 files.
• Integration tests pass
  • Full engine-bridge and dashboard suites passed.
• Manual smoke test performed
  • Not performed; this is an internal cache-bound fix covered by a deterministic asynchronous regression test.
• TypeScript builds pass
  • engine-bridge: npm run build
  • dashboard: npm run build
• Lint checks pass
  • engine-bridge: npm run lint — 0 errors.
  • dashboard: npm run lint — passed.
• WASM release build passes
  • cargo build --target wasm32-unknown-unknown --release
• Diff validation passes
  • git diff --check

Checklist

• Branch follows naming convention (fix/201-revalidation-lru-bound)
• Closes #201 reference is present above (linking this PR to the issue)
• Code follows the project's style and conventions
• New or updated tests cover the changes
• Documentation updated if behaviour changed
  • No documentation changes were required because no public API or configuration behavior changed.
• No secrets, credentials, or sensitive data committed
• PR is scoped to a single concern (one issue per PR)